Remarks 



This paper represents Applicants' first opportunity to comment on the new rejection to 
the pending claims set forth in the final Office Action. For the reasons stated herein, Applicant 
requests that the Examiner reconsider and withdraw the rejection set forth in the final Office 
Action. Further, Applicant respectfully submits that all claims are in condition for allowance. 
Claims 1-11 remain pending. 

In the final Office Action, claims 1-1 1 were rejected under 35 U.S.C. §103(a) as being 
obvious over Latif et al. (U.S. Patent No. 6,393,483 Bl; hereinafter Latif) in view of Chen et al. 
(U.S. Patent No. 5,831,975; hereinafter Chen). This rejection is respectfully, but most 
strenuously, traversed and reconsideration and withdrawal thereof are requested. 

Applicant requests reconsideration and withdrawal of the obviousness rejection on at 
least the following grounds: 

(1) The final Office Action fails to state a prima facie case of obviousness 
against Applicant's claimed invention; 

(2) The final Office Action has misinterpreted the teachings of Latif and 
Chen, thus voiding the basis for the rejection; and 

(3) The applied art would not be combined as proposed, and lacks any 
teaching, suggestion or incentive for its further modification as necessary 
to achieve Applicant's recited invention. 

Failure to State a Prima Facie Case o f Obviousness: 

The rejection set forth is believed clearly deficient in stating a prima facie case of 
obviousness. To support a conclusion that the claimed invention is directed to obvious subject 
matter, either the references must expressly or impliedly suggest the claimed invention or the 
Examiner must present a convincing line of reasoning as to why the artisan would have found the 
claimed invention to have been obvious in light of the teachings of the references. MPEP 
§706.020). 
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In this case, the final Office Action presents little reasoning regarding the relevancy of 
the concepts of Latif to Applicant's claimed invention. Thus, Applicants understand that the 
final Office Action is asserting that the Latif patent itself teaches those aspects of Applicant's 
recited invention as set forth at page 3, line 15 - page 4, line 4 of the final Office Action. Such a 
conclusion is believed clearly not supported by the teachings of Latif cited in the final Office 
Action (i.e., FIG. 2; column 5, lines 10-67; column 7, lines 1-55 & column 11, lines 21-45). 

More particularly, the final Office Action repeats the language of Applicant's claims, and 
then asserts in parentheses particular teachings of Latif which supposedly teach or suggest the 
recited invention. However, Applicant respectfully submits that the differences between the 
environment and the functionality of his claimed invention in comparison with Latif are so 
numerous as to render any parenthetical comparison to specific teachings of Latif deficient. For 
example, Applicant recites in claim 1 : 

A processing method for a distributed computing environment 
having multiple networks of computing nodes employing multicast 
messaging, each network having at least one computing node, at 
least one computing node of said multiple networks of computing 
nodes functioning as a multicast routing node 

In stating the rejection, the final Office Action repeats the language of Applicant's claim 1 and 
then cites FIG. 2, as well as column 5, lines 29-67 of Latif. However, the citation is clearly 
deficient since a careful reading of Latif fails to uncover any discussion of: 

(1) Networks of computing nodes employing multicast messaging; and 

(2) At least one computing node of the multiple networks of computing nodes 
functioning as a multicast routing node. 

The term "multicast messaging" refers to a specific messaging protocol which is distinct 
from standard internet protocol routing. A "multicast routing node" refers to a particular type of 
node performing particular functions associated with multicast messaging. As known in the art, 
multicast messaging is a particular communications protocol wherein one sender sends a single 
message to many receivers. Thus, to the extent that the final Office Action at page 3 asserts that 
Latif describes the environment set forth in claim 1 , Applicant respectfully submits that the 
rejection is deficient. 
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This is expressly recognized in the final Office Action at page 4 where it is stated that 
"Latif does not teach a multicast routing functionality with multicast routing nodes in a 
distributed environment to maintain multicast message reachability." 

In view of this inconsistency of the final Office Action, Applicant is unable to address 
any alleged relevancy of Latif, and therefore respectfully submits that a prima facie case of 
obviousness is not stated in the rejection set forth. Reconsideration and withdrawal of the 
rejection is therefore requested. 

Still further, Applicant recites processing which includes: 

• Automatically responding to failure of a computing node functioning 
as multicast routing node of the at least one computing node 
functioning as the multicast routing node to reassign the multicast 
routing function. 

Again, the final Office Action merely cites column 5, lines 10-28 of Latif for allegedly 
teaching this aspect of his recited invention. However, the citation is believed deficient. A 
careful reading of Latif, column 5, lines 10-28 fails to uncover any teaching of: 

(1) Automatically responding to a failure of a computing node; 

(2) Automatically responding to a failure of a computing node functioning as 
multicast routing note; or 

(3) Automatically responding to a failure of a computing node functioning as 
multicast routing node to reassign the multicast routing function. 

A careful reading of Latif, column 5, lines 10-28, fails to uncover any discussion of an 
automatic response to failure of a computing node functioning as multicast routing node. In 
addition, there is no failure of a computing node per se described in Latif. Rather, Latif 
describes failure of a network interface card (NIC) within a host or server. The host/server 
equates to a node in one of the networks. Since the server itself does not fail, but rather only a 
component of the server fails, i.e., the internet NIC card, the teachings of Latif do not equate to 
Applicant's recited process (wherein there is a failure of the computing node itself). As such, 
there can be no automatically responding to failure of a computing node per se, let alone 
automatically responding to the failure of a computing node that functions as a multicast routing 
node. 
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Further, Applicant is unable to understand the rejection set forth in the final Office 
Action in this regard. It appears at page 4, lines 5-6 that the Examiner recognizes that Latif only 
describes failing ports, instead of failing nodes, notwithstanding the citation at page 3 of column 
5, lines 10-28 of Latif. Based on this express inconsistency, Applicant respectfully submits that 
a prima facie case of obviousness is not set forth in the final Office Action. Applicant is unable 
to ascertain the alleged relevancy of column 5, lines 10-28 to the particular functionality recited 
in the independent claims presented. 

Still further, Applicant recites: 

• wherein the automatically responding includes dynamically 
reconfiguring the distributed computing environment to 
replace each failed multicast routing node of the at least one 
multicast routing node with another computing node of the 
multiple networks of computing nodes to maintain multicast 
message reachability to all functional computing nodes of the 
distributed computing environment. 

With respect to this functionality, the final Office Action again repeats the language at issue and 
cites column 5, lines 10-67, column 7, lines 1-55, & column 11, lines 21-45 of Latif. However, 
the final Office Action then recognizes that Latif does not describe the existence of a failing 
node, let alone the existence of a multicast routing node which fails. 

For similar reasons for those stated above, Applicant is unable to understand the 
relevancy of the cited lines of Latif to the repeated functionality of Applicant's recited invention 
at issue. There is no dynamic reconfiguring of a distributed computing environment to replace a 
failed multicast routing node in Latif. Further, there is no dynamic reconfiguring of the 
distributed computing environment in a manner which allows for maintenance of multicast 
message reachability to all functional computing nodes of the distributed computing environment 
in Latif. Thus, Applicant respectfully submits that columns 5, 7 & 1 1 of Latif are not relevant to 
the language at issue. As such, Applicant respectfully submits that the final Office Action fails 
to state a prima facie case of obviousness against the independent claims presented. 
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Yet further, the final Office Action combines the teachings of Chen with those of Latif, 
and alleges that Chen teaches that a failing port could comprise a failing node, and that the Latif 
concepts could be employed in a multicast routing functionality with multicast routing nodes in a 
distributed environment to maintain multicast message reachability. Applicant respectfully, but 
most strenuously, traverses these characterizations of the teachings of Chen. 

Chen describes extending the PNNI protocols to support hierarchical multicast routing 
and signaling for ATM networks. Chen utilizes an extension of a core-based tree algorithm 
wherein core nodes are maintained in each peer group and at each level of the hierarchy. The 
advantage of the Chen approach is that a single core node is not overloaded. Additionally, this 
creates fault-tolerance because there is no single point of failure. 

Applicant respectfully submits that a careful reading of Chen, as well as the final Office 
Action, fails to uncover any discussion of failure of a computing node presented in Chen, let 
alone failure of a computing node functioning as multicast routing node. Still further, a careful 
reading of Chen and the final Office Action fails to uncover any discussion of automatically 
responding to the failure by dynamically reconfiguring the distributed computing environment to 
replace each failed multicast routing node to maintain multicast message reachability to all 
functional computing nodes. Since, as noted above, these aspects of the invention are not 
described by Latif, as expressly recognized at page 4 of the final Office Action, and since the 
aspects are not described by Chen, nor asserted in the final Office Action to be described by 
Chen, it is respectfully submitted that the final Office Action fails to state a prima facie case of 
obviousness against the claims presented. 

The Final Office Action Mischaracterizes the Teachings of Latif and Chen: 

Latif discloses a process for driving a network interface card. The process includes: 
monitoring the status of a plurality of ports connected between a computer and a network; 
detecting a failure in one of the plurality of ports connected to the network; and reassigning data 
transmitted over the failed port to an active port of the plurality of ports selected in a round-robin 
technique. The process further includes receiving data over one of the ports designated as a 
primary receiving port. When the failed one of the plurality of ports is the primary receiving 
port, the receiving tasks are assigned to a next active port selected in a round-robin technique. 
(See Abstract of Latif.) 
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In addition to failing to state a prima facie case of obviousness against the independent 
claims at issue, Applicant respectfully submits that the final Office Action mischaracterizes the 
teachings of Latif by repeating the language of Applicant's recited invention and then simply 
citing various columns and figures from Latif. As noted in detail above, the environment and 
process recited by Latif are simply not relevant to Applicant's recited invention and process. 

A careful reading of Latif, in particular, FIG. 2 & column 5, lines 10-67, column 7, lines 
1-55 & column 11, lines 21-45, fails to uncover any discussion of the environment recited by 
Applicant in the claims at issue. 

Specifically, Applicant recites a distributed computing environment wherein there are 
multiple networks of computing nodes which employ multicast messaging. There is no 
discussion in Latif of multicast messaging per se, which as noted above, is a particular type of 
messaging protocol distinct from standard internet protocol. Further, Applicant's claims recite 
that one of the nodes in at least one of the networks functions as a multicast routing node. A 
multicast routing node is a particular node having multicast routing functionality, as recited in 
the claims. No multicast routing functionality is described in Latif, nor in the parenthetical 
citations of the final Office Action citing various columns and figures of Latif. As such, 
Applicant respectfully submits that the final Office Action mischaracterizes the teachings of 
Latif when simply restating the language of claim 1 of the present invention and then alleging 
certain relevancy to various columns and figures in Latif. This mischaracterization appears to be 
recognized in the final Office Action at page 4, where it is noted that Latif discloses failing ports, 
but not failing nodes; and that Latif does not teach a multicast routing functionality with 
multicast routing nodes in a distributed computing environment to maintain multicast message 
reachability. Based on this inconsistency, Applicant is unable to ascertain the alleged relevancy 
of Latif to his recited invention. 

Additionally, Applicant respectfully submits that the final Office Action mischaracterizes 
the teachings of Chen to the extent that the final Office Action alleges that Chen teaches the 
deficiencies of Latif when applied against the claims at issue. At page 4 of the final Office 
Action, with respect to Chen, it is stated: 
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... the scheme is highly scalable to large networks because routers have to 
maintain only one tree per multicast group. The method supports dynamic 
membership to a multicast group, in that, nodes can join or leave the 
multicast group during the course of the multicast. Multiple senders to the 
multicast group are also supported, which enables realization of a true 
multipoint-to-multipoint connection. In addition, the multicast tree can be 
dynamically changed to reflect changes in the node and link states (see 
Chen, column 7, lines 53-63). 

Initially, Applicant notes that the cited material from Chen does not describe detection or 
responding to failure of a computing node functioning as a multicast routing node, as 
specifically recited in the independent claims at issue. 

Further, Applicant notes that the cited material from Chen does not teach or suggest that 
responsive to failure of a computing node functioning as multicast routing node, there is an 
automatic reassigning of the multicast routing function. Still further, Applicant respectfully 
submits that a careful reading of the cited material of Chen does not address that the automatic 
responding includes dynamically reconfiguring the environment to replace each failed multicast 
routing node to maintain multicast messaging reachability to all functional computing nodes. To 
the extent relevant, Chen simply describes a conventional multicast routing environment where 
nodes can join or leave a multicast group during the course of the multicast. There is simply no 
discussion in Chen of failure at a multicast routing node. In the language of Chen, the core node 
functions as the multicast routing node and Chen assumes that the core nodes will not change. 
(See column 8, lines 40-42 of Chen.) 

To summarize, Latif does not describe failure of a node per se within a distributed 
computer environment, but rather failure of a port (NCI) card. As such, Latif cannot teach or 
suggest a process for automatically responding to failure of a node, let alone responding by the 
dynamic reconfiguration of the distributed computing environment to transfer multicast routing 
functionality as recited in Applicant's independent claims. 

Further, there is no teaching of multicast messaging per se, let alone the provision of 
multicast routing functionality at a particular node, nor of a facility for automatically responding 
to failure of the node having the multicast routing functionality to automatically transfer that 
functionality to another node of the network of the distributed computing environment. 
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Multicast messaging and multicast routing functionality are known terms and refer to a particular 
type of messaging protocol. This messaging protocol is not taught by Latif. 

Although Chen describes a multicast routing environment, a careful reading thereof fails 
to uncover any discussion of failure of a computing node thereof functioning as multicast routing 
node, or of automatically responding thereto by reassigning the multicast routing function. Still 
further, Applicant respectfully submits that a careful reading of Chen fails to uncover any 
teaching or suggestion that this automatically responding includes dynamically reconfiguring the 
distributed computing environment to replace each failed multicast routing node with another 
computing node of the multiple networks of computing nodes to maintain the multicast message 
reachability to all functional computing nodes. 

For at least the above-noted reasons, Applicant respectfully submits that the independent 
claims patentably distinguish over the applied art. Reconsideration and withdrawal of the 
rejection to these claims is therefore requested. 

The Applied Art Would Not be Combined as Proposed, and Lacks any Teaching, 
Suggestion or Incentive for its Further Modification as Necessary to Achieve 
Applicant 's Recited Invention: 

As noted, Latif discloses a process for driving a network interface card. The process 
includes monitoring the status of a plurality of ports connected between a computer and a 
network, detecting a failure in one of the plurality of ports connected to the network, and 
reassigning data transmitted over the failed port to an active port of the plurality of ports selected 
in a round-robin technique. At column 11, lines 8-20, Latif teaches: 

As will be described with reference to FIG. 9 below, a PRT timer route is 
controlled by the smart NIC driver 126 which scans all indicies of the PRT 
table and associated connected hosts to determine whether they are or are 
not actively transmitting data. In an initial scan, if the timer is currently 
set to "1," then the timer will be changed to "0" if the port is inactive. 
After a predetermined time-out, the smart NIC 126 will again scan all 
indices (i.e., from 0 to 225) of the PRT table and associated hosts, and 
again change all timers that are currently set to "1," to "0." However, if 
the timer is already set to "0," the smart NIC driver 126 will remove the 
connection to that remote host, and thereby make the port assigned to that 
host free. 
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Latif s process for monitoring for port failure relies upon a single smart NIC driver 126. This 
centralized failure detection and recovery approach would simply not be applicable to a 
distributed computing environment having multiple networks of computing nodes employing 
multicast messaging as recited in the independent claims presented. In Latif, the smart NIC 
driver scans the indices of a PRT table to determine if a particular port is transmitting data or not. 
In a distributed network such as recited in the claims presented, there is no single entity that has 
access to all the other nodes, and more particularly, to the multicast routing nodes. Thus, Latif s 
approach would simply not be applicable to an environment such as recited in the independent 
claims presented. In a multicast network environment, there is no one entity given access to all 
the other nodes. This is in part due to technology reasons, as well as scalability. Thus, Latif is 
describing a fundamentally different technology than could be applied in a distributed computing 
environment such as recited in the claims at issue. Since there is no central point which is in 
communication with each of the core nodes, it would not be possible to employ the centralized 
approach of Latif in the distributed environment of Chen. 

Further, a careful reading of Chen fails to uncover any teaching or suggestion of a 
process for recovery should one of the core nodes fail. 

For these additional reasons, Applicant respectfully requests reconsideration and 
withdrawal of the rejection stated in the final Office Action. 

Conclusion: 

Applicant respectfully submits that the pending independent claims patentably 
distinguish over the teachings and suggestions of Latif and Chen. The dependent claims are 
believed allowable for the same reasons as the independent claims, as well as for their own 
additional characterizations. 

For example, with respect to claim 2, Applicant recites that each group leader is coupled 
by a virtual interface to at least one other group leader of the computing nodes. The term 
"virtual interface" is a term of art that is associated with protocol encapsulation. A careful 
reading of Chen fails to uncover any discussion of the creation or maintenance of a virtual 
interface. 
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Further, Applicant's claims 2 & 6 recite that the failure occurs at a group leader node 
and that there is automatic selection of a new group leader from functioning computing nodes of 
the respective group of group leaders having the group leader failure. No similar functionality is 
taught or suggested by Chen. 

Still further, dependent claims 3 & 7 recite that the virtual interface is a multicast 
messaging tunnel between group leaders. A careful reading of Chen, and in particular, column 8, 
lines 16-57, fails to uncover any discussion relevant to this aspect of Applicant's invention. 
There is simply no discussion of a virtual interface comprising a multicast messaging tunnel 
between group leaders in Chen. Further, there is no discussion in Chen that the multicast 
messaging tunnel is established using a particular daemon, that is, an m-routed daemon. 

For at least the above reasons, all claims are believed to be in condition for allowance and 
such action is respectfully requested. 

If a telephone conference would be of assistance in advancing prosecution of the subject 
application, Applicant's undersigned attorney invites the Examiner to telephone him at the 
number provided. 



Dated: June Q( 0 , 2006. 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 

Albany, New York 12203-5160 

Telephone: (518)452-5600 

Facsimile: (518)452-5579 



Respectfully submitted, 




Kevin P. Radigan Qj 
Attorney for Applicant 
Registration No.: 31,789 
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